iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 8
1
DevOps

誤入 Ops 叢林的 Dev 小白兔系列 第 8

人生就是在不斷的被拒絕後,找到希望(5/5)

  • 分享至 

  • xImage
  •  

今天的故事是延自上兩篇的後續自動化處理,讓我再把整個細節稍加補充,最一開始我們是先使用 google sheet 表單當作資料庫,程式會定期去表單抓取每一個群組可用的線路設定,所以當臨時頁面上出現線路資料的服務等級不為 0 的時候,維運人員到 google sheet 上,找到該筆線路資料,移除該資料,然後換成其他備用的線路資訊。

範例:當臨時頁面出現〔線路123〕服務等級5,那就要把〔線路123〕從表格移除,然後換成〔線路456〕。

google sheet 當作資料庫當然只是臨時的,當開發團隊安排把資料存入其他設備,下一步就是要製作後台操作頁面供維運團隊使用了,當時在設計的操作介面時,想著要分群組顯示顯示資料,維運團隊就可以分群組逐一處理,為了避免重蹈之前的錯誤,所以這次在開發團隊討論完預計的功能設計時,便先去找維運工程師確認這是否是他們所需要的?

當把我們想好的方案提議給維運工程師時,維運工程師表示
『我們沒有要每個群組逐一檢查耶...』
「嗯?不然你們都是怎麼處理」(訝異的睜大眼睛)
『有問題的直接換過去就好了。』
「嗯...還是你先說一下現在你們怎麼處理?」
『我會把檢查出來的資料,跟備用的線路資料配對,然後把 google sheet 上的資料抓下來,用程式直接產生新的一份檔案,再直接複製貼到 google sheet 上』
「所以只要等級不為 0 的就換,你們不用再做二次確認嗎?」
『對喔!反正我們來說,有問題就是得換』
「哪個資料換不用知道嗎?」
『有記錄就可以,還要可以看到當下每個群組適用的線路資訊就好』
「好」

老實說,當我聽到維運工程師的處理方式出乎意料,就如前一篇文章所敘述的,以往我所面對的使用者都是非工程師,很少遇到可以自行先做小工具來補足我們系統尚未提供的服務,另一部分感到意外的部分是我從還沒有想到這樣換,感覺好像自己的腦袋已經被限縮在特定的範圍裡。

談需求時與其自己憑空想像,不如直接詢問維運團隊操作步驟,然後針對每個步驟去詢問跟設想不同的可能性,慢慢探究操作步驟的每個原因,然後再進行設計規劃,才能淬煉出實際幫助較大的功能。


上一篇
人生就是在不斷的被拒絕後,找到希望(4/5)
下一篇
為什麼要用爬的?!(1/2)
系列文
誤入 Ops 叢林的 Dev 小白兔30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言